http://www.netbsd.org/docs/guide/en/chap-mail.html
<quote>
Note:
Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
and sendmail was removed.
</quote>


--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

On Dec 20, 12:46 am, Andrzej Adam Filip <a... [at] onet.eu> wrote:
> http://www.netbsd.org/docs/guide/en/chap-mail.html
> <quote>
> Note:
> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> and sendmail was removed.
> </quote>

NetBSD does not represent much of a percentage in usage out there....
No big loss. Too bad though. I used to recommend NetBSD over all other
free BSDs available as a viable alternative in some installations due
to
its wonderful cross platform portability. Now maybe not so...
At least sendmail is in the ports section

I am curious about how this decision was reached and why the core team
approved this little gem of an idea.
I recognise only one name in the core team now.
Are they are on a path of obscurity to nowhere?? : >

I am surprised that anyone is still using NetBSD.

That said, I have administered sendmail for about 11 years, and had a
large amount of hard to diagnose frustrations over the years. I am not
qualified to say that postfix is better.

For new computers that are not mail servers, I use debian and exim4.

i

usenetpersongerryt [at] gmail.com writes:

> On Dec 20, 12:46 am, Andrzej Adam Filip <a... [at] onet.eu> wrote:
>> http://www.netbsd.org/docs/guide/en/chap-mail.html
>> <quote>
>> Note:
>> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
>> and sendmail was removed.
>> </quote>
>
> NetBSD does not represent much of a percentage in usage out there....

NetBSD *alone* may be not too important but do not try to pretend that
it is not YASD (Yet Another Similar Decision) in a pretty long string
of similar moves.

> No big loss. Too bad though. I used to recommend NetBSD over all other
> free BSDs available as a viable alternative in some installations due
> to its wonderful cross platform portability. Now maybe not so...
> At least sendmail is in the ports section
>
> I am curious about how this decision was reached and why the core team
> approved this little gem of an idea.
> I recognise only one name in the core team now.
> Are they are on a path of obscurity to nowhere?? : >

IF you pretend that there is no problem (long trend of pting-out from
sendmail use or sendmail as default MTA) THEN you pretend that there is
nothing to fix.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

Ignoramus31412 <ignoramus31412 [at] NOSPAM.31412.invalid> writes:

> I am surprised that anyone is still using NetBSD.
>
> That said, I have administered sendmail for about 11 years, and had a
> large amount of hard to diagnose frustrations over the years. I am not
> qualified to say that postfix is better.
>
> For new computers that are not mail servers, I use debian and exim4.

Who are you? Anonymous opinions count less (usually).

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/

On 2007-12-20, Andrzej Adam Filip <anfi [at] onet.eu> wrote:
> Ignoramus31412 <ignoramus31412 [at] NOSPAM.31412.invalid> writes:
>
>> I am surprised that anyone is still using NetBSD.
>>
>> That said, I have administered sendmail for about 11 years, and had a
>> large amount of hard to diagnose frustrations over the years. I am not
>> qualified to say that postfix is better.
>>
>> For new computers that are not mail servers, I use debian and exim4.
>
> Who are you? Anonymous opinions count less (usually).
>

What do you want, my name?

i

usenetpersongerryt [at] gmail.com wrote:
: On Dec 20, 12:46 am, Andrzej Adam Filip <a... [at] onet.eu> wrote:
: > http://www.netbsd.org/docs/guide/en/chap-mail.html
: > <quote>
: > Note:
: > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
: > and sendmail was removed.
: > </quote>

: NetBSD does not represent much of a percentage in usage out there....
: No big loss. Too bad though. I used to recommend NetBSD over all other
: free BSDs available as a viable alternative in some installations due
: to
: its wonderful cross platform portability. Now maybe not so...
: At least sendmail is in the ports section

Where it is always up to date and has more options (i.e. STARTTLS,
SASL, LDAP, etc).

Just a nitpick... In NetBSD nomenclature a "port" is support for
a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
The packaging system is called "pkgsrc". Of note, is that pkgsrc
supports multiple platforms including, NetBSD, Linux, Interix
(Microsoft Services for Unix), Solaris, etc. In this way, modern
sendmail is brought to a number of platforms that may not otherwise
have a current version of sendmail available.

: Are they are on a path of obscurity to nowhere?? : >

Keep your eyes open, there's a lot of great stuff happening in
NetBSD.

In article <476ae895$1 [at] news.victoria.tc.ca>,
jnemeth [at] vtn1.victoria.tc.ca (John Nemeth) writes:
> usenetpersongerryt [at] gmail.com wrote:
>: On Dec 20, 12:46 am, Andrzej Adam Filip <a... [at] onet.eu> wrote:
>: > http://www.netbsd.org/docs/guide/en/chap-mail.html
>: > <quote>
>: > Note:
>: > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
>: > and sendmail was removed.
>: > </quote>
>
>: NetBSD does not represent much of a percentage in usage out there....
>: No big loss. Too bad though. I used to recommend NetBSD over all other
>: free BSDs available as a viable alternative in some installations due
>: to
>: its wonderful cross platform portability. Now maybe not so...
>: At least sendmail is in the ports section
>
> Where it is always up to date and has more options (i.e. STARTTLS,
> SASL, LDAP, etc).
>
> Just a nitpick... In NetBSD nomenclature a "port" is support for
> a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
> The packaging system is called "pkgsrc". Of note, is that pkgsrc
> supports multiple platforms including, NetBSD, Linux, Interix
> (Microsoft Services for Unix), Solaris, etc. In this way, modern
> sendmail is brought to a number of platforms that may not otherwise
> have a current version of sendmail available.
>
>: Are they are on a path of obscurity to nowhere?? : >
>
> Keep your eyes open, there's a lot of great stuff happening in
> NetBSD.

As Mark Twain (Samuel Clemens) said on reading his own
obituary, "The reports of my death are greatly exaggerated."

This strikes me as typical FUD from a member of that segment
of the community that knows nothing about the BSDs. Pity.

Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Thinking is the hardest work there is, which is the probable
reason so few engage in it. -- Henry Ford

On 2007-12-20, Ignoramus31412 <ignoramus31412 [at] NOSPAM.31412.invalid> wrote:

> I am surprised that anyone is still using NetBSD.
>
> That said, I have administered sendmail for about 11 years, and had a
> large amount of hard to diagnose frustrations over the years. I am not
> qualified to say that postfix is better.
>
> For new computers that are not mail servers, I use debian and exim4.

I use FreeBSD, NetBSD, and linux. FreeBSD runs the mail server
(sendmail) and apache, NetBSD runs a tor client for my network, and
linux on the desktop and a tor exit node.

--

John (john [at] os2.dhs.org)

On Dec 20, 2:11 pm, jnem... [at] vtn1.victoria.tc.ca (John Nemeth) wrote:
> usenetpersonger... [at] gmail.com wrote:
> : On Dec 20, 12:46 am, Andrzej Adam Filip <a... [at] onet.eu> wrote:
> : >http://www.netbsd.org/docs/guide/en/chap-mail.html
> : > <quote>
> : > Note:
> : > Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> : > and sendmail was removed.
> : > </quote>
> : NetBSD does not represent much of a percentage in usage out there....
> : No big loss. Too bad though. I used to recommend NetBSD over all other
> : free BSDs available as a viable alternative in some installations due
> : to
> : its wonderful cross platform portability. Now maybe not so...
> : At least sendmail is in the ports section
> Where it is always up to date and has more options (i.e. STARTTLS,
> SASL, LDAP, etc).

I thought maybe this was the case.
Not familiar with postfix so I didnt FUD anything : >

> Just a nitpick... In NetBSD nomenclature a "port" is support for
> a particular architechure (i.e. i386, amd64, macppc, sparc64, etc).
> The packaging system is called "pkgsrc". Of note, is that pkgsrc
> supports multiple platforms including, NetBSD, Linux, Interix
> (Microsoft Services for Unix), Solaris, etc. In this way, modern
> sendmail is brought to a number of platforms that may not otherwise
> have a current version of sendmail available.

yes

> : Are they are on a path of obscurity to nowhere?? : >
> Keep your eyes open, there's a lot of great stuff happening in
> NetBSD.

I try to keep them open : >
I still like NetBSD for reasons Ive already stated but it seems weird
to
"remove" sendmail. Especially sendmail, as it's been a core app from
the beginning of BSD days.

I'll drop in what Andrei says here and comment:

>NetBSD *alone* may be not too important but do not try to pretend that
>it is not YASD (Yet Another Similar Decision) in a pretty long string
>of similar moves.

You dont have to tell a person whose thing is Sun/Solaris/SPARC THAT.

One could get the impression that sendmail itself is getting a bit
stale.
First we had Sendmail X and then Herr Claus moved over to something
else.
Patches for 8.14 yes but momentum seems to be drifting a bit?

People goto postfix because ... the perception is its "easier" to
configure?
Or is it just that to run sendmail competently you might actually have
to know
something about your JOB..??

[appalling article formatting fixed]

In article
<48b65bee-0e26-4a64-b535-3b587c964c72 [at] e6g2000prf.googlegroups.com>,
usenetpersongerryt [at] gmail.com wrote:

> People goto postfix because ... the perception is its "easier" to
> configure?

As someone who uses both Postfix and Sendmail, I think that is not
purely perception. More important than the "easiness" is the clarity of
the configuration of a system. If you work with Sendmail all the time
and have done so for a long time, the quirks don't feel so quirky, but
if you are not so experienced with Sendmail specifically and/or are not
continuously immersed in working with it, the nature of the
configuration makes it hard to just read the files and understand.
Postfix's configuration is substantially more accessible and
comprehensible for the general admin whose work with email is almost
entirely maintenance of a generally functional system. A large fraction
of people managing Sendmail systems are cargo-cultists who don't really
understand their configs, they just know the rituals of tweaking a .mc
with whatever they can find here or on some web page and running Build.
Postfix

> Or is it just that to run sendmail competently you might
> actually have to know something about your JOB..??

The same is true of non-trivial Postfix systems, because any mail system
has to map the complexity of what people want their mail system to do
onto the non-obvious details of how that can be implemented with
Internet email.

A significant issue in this general realm is that for the majority of
modern Unix(ish) systems, the local MTA really isn't supposed to be
doing anything terribly complex in concept and does not need any changes
for very long periods, so is likely to be maintained by a person or team
that mostly just relies on the MTA doing the right thing until the rare
event requires some small change. For the admin whose main job is more
about a half-dozen other arcane areas than it is about email, Postfix
provides an alternative that is less likely to require a day of research
to make small changes to.

More generally, Postfix has some objective advantages over Sendmail in
the area of modular design with the resulting security advantage and in
the support of facilities like kqueue, epoll and /dev/poll (on systems
that do them well) that make it feasible to handle huge numbers of
concurrent connections. It has become very hard to make an argument for
Sendmail on any basis other than "It's what I know" and that's pretty
weak.

--
Now where did I hide that website...

Bill Cole wrote:

> More generally, Postfix has some objective advantages over Sendmail in
> the area of modular design with the resulting security advantage and in
> the support of facilities like kqueue, epoll and /dev/poll (on systems
> that do them well) that make it feasible to handle huge numbers of
> concurrent connections. It has become very hard to make an argument for
> Sendmail on any basis other than "It's what I know" and that's pretty
> weak.

We sell a commercial anti-spam system implemented as a milter, and we
have had pushback for being tied to Sendmail. Some large customers and
potential customers grumble about the need to have a Sendmail relay, and
typically they propose Postfix as the alternative. Postfix now fully
supports milter, so at some point we will look at integrating with it.

One of the big problems is the lack of direction from the Sendmail
developers. On the one hand, I can understand the reluctance to provide
a roadmap because roadmaps are typically guessed at to appease PHBs and then
developers find themselves constrained by the roadmap and can't react quickly
to changing circumstances.

On the other hand, having at least some inkling of the future direction
of Sendmail would be nice. Is Sendmail 8.x going to continue to be
developed? What's the official status of MeTA1? Will there be an
upgrade path from Sendmail 8 to MeTA1?

http://www.sendmail.org/news/ is stale by more than a year.
http://www.sendmail.com/ is just an ad that (incorrectly) claims
to be the "first" appliance to filter both inbound and outbound mail.
(There are supposed to be navigation menus on that page, I guess,
but they do not render in Firefox.)

Regards,

David.

"David F. Skoll" <dfs [at] roaringpenguin.com> writes:
> [...]
> We sell a commercial anti-spam system implemented as a milter, and we
> have had pushback for being tied to Sendmail. Some large customers
> and potential customers grumble about the need to have a Sendmail
> relay, and typically they propose Postfix as the alternative. Postfix
> now fully supports milter, so at some point we will look at
> integrating with it.

Have you heard about any *serious* attempt to provide core functionality
provided by milter protocol via *open* protocol? [e.g. LMTP based]

[AFAIK Milter *protocol* (not API) has never been documented by sendmail.org ]

> [...]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Live within your income, even if you have to borrow to do so.
-- Josh Billings

Andrzej Adam Filip wrote:

> Have you heard about any *serious* attempt to provide core functionality
> provided by milter protocol via *open* protocol? [e.g. LMTP based]

No, not really. Postfix does have an open SMTP-based filtering
protocol, but it's not as full-featured or flexible as Milter.

> [AFAIK Milter *protocol* (not API) has never been documented by
> [sendmail.org ]

Correct, and it's theoretically an internal API subject to change.
However, it's stable enough that the Postfix author(s) felt comfortable
reverse-engineering it and implementing the MTA side of milter.

Samba has succeeded quite nicely in implementing undocumented and
ever-shifting protocols; Milter is at least two orders of magnitude
simpler to reverse-engineer and support.

Regards,

David.

In article <983a4$476d3206$d1d97a75$4156 [at] PRIMUS.CA>,
"David F. Skoll" <dfs [at] roaringpenguin.com> wrote:

> Bill Cole wrote:
>
> > More generally, Postfix has some objective advantages over Sendmail in
> > the area of modular design with the resulting security advantage and in
> > the support of facilities like kqueue, epoll and /dev/poll (on systems
> > that do them well) that make it feasible to handle huge numbers of
> > concurrent connections. It has become very hard to make an argument for
> > Sendmail on any basis other than "It's what I know" and that's pretty
> > weak.
>
> We sell a commercial anti-spam system implemented as a milter, and we
> have had pushback for being tied to Sendmail. Some large customers and
> potential customers grumble about the need to have a Sendmail relay, and
> typically they propose Postfix as the alternative. Postfix now fully
> supports milter, so at some point we will look at integrating with it.

FWIW, I've been running a small Postfix system with MIMEDefang for 4
months and haven't run into any significant problems. If the commercial
product isn't too far from MD, you may not have much work to do...

You also might want to look at Dr. Venema's latest post on this to the
Postfix Users list. He discusses the gaps between his 'version 6' milter
implementation and the latest Sendmail implementation, complete with
reasons why some gaps are likely to never be closed.

> One of the big problems is the lack of direction from the Sendmail
> developers. On the one hand, I can understand the reluctance to provide
> a roadmap because roadmaps are typically guessed at to appease PHBs and then
> developers find themselves constrained by the roadmap and can't react quickly
> to changing circumstances.
>
> On the other hand, having at least some inkling of the future direction
> of Sendmail would be nice. Is Sendmail 8.x going to continue to be
> developed? What's the official status of MeTA1? Will there be an
> upgrade path from Sendmail 8 to MeTA1?
>
> http://www.sendmail.org/news/ is stale by more than a year.
> http://www.sendmail.com/ is just an ad that (incorrectly) claims
> to be the "first" appliance to filter both inbound and outbound mail.
> (There are supposed to be navigation menus on that page, I guess,
> but they do not render in Firefox.)

I can't discuss Sendmail Inc. without coming across cattier than they
deserve. It's an exasperating situation.

--
Now where did I hide that website...

In article <242b$476d4072$d1d97a75$20187 [at] PRIMUS.CA>,
"David F. Skoll" <dfs [at] roaringpenguin.com> wrote:

> Andrzej Adam Filip wrote:
>
> > Have you heard about any *serious* attempt to provide core functionality
> > provided by milter protocol via *open* protocol? [e.g. LMTP based]
>
> No, not really. Postfix does have an open SMTP-based filtering
> protocol, but it's not as full-featured or flexible as Milter.
>
> > [AFAIK Milter *protocol* (not API) has never been documented by
> > [sendmail.org ]
>
> Correct, and it's theoretically an internal API subject to change.
> However, it's stable enough that the Postfix author(s) felt comfortable
> reverse-engineering it and implementing the MTA side of milter.
>
> Samba has succeeded quite nicely in implementing undocumented and
> ever-shifting protocols; Milter is at least two orders of magnitude
> simpler to reverse-engineer and support.

Or better...

After all, Samba has a reference implementation which it has to match
that can only be examined as a black box, while anyone trying to
replicate Milter has BSD-licensed source code for the reference
implementation.

The problem there is apparently that some of Milter requires an MTA
design better suited to the last century. MeTAl and Postfix have had
similar gaps in their implementations, and while I have not dug deep
into the code to get a direct understanding of the details, I trust Dr.
Venema's descriptions of the challenges.

--
Now where did I hide that website...

David F. Skoll wrote:

> On the other hand, having at least some inkling of the future direction
> of Sendmail would be nice.

[line breaks added to make it simpler to insert answers]
> Is Sendmail 8.x going to continue to be developed?

Yes. However, it should be obvious to everyone that there
is no need for any major changes (ESMTP isn't changing,
almost all extensions can be done via milters.) All open
source MTAs basically "simply work", so everyone can choose
an MTA based on her/his personal preferences.

> What's the official status of MeTA1?

MeTA1 is NOT a Sendmail Consortium project. MeTA1 is under
development, and the website is updated whenever a new
version is released.

> Will there be an upgrade path from Sendmail 8 to MeTA1?

If someone writes the code... (it won't be me; I consider
other parts more interesting so I'm working on those as
MeTA1 is something I do in my spare time).

Claus Aßmann
<ca+sendmail(-no-copies-please) [at] mine.informatik.uni-kiel.de> writes:

> David F. Skoll wrote:
>
>> On the other hand, having at least some inkling of the future direction
>> of Sendmail would be nice.
>
> [line breaks added to make it simpler to insert answers]
>> Is Sendmail 8.x going to continue to be developed?
>
> Yes. However, it should be obvious to everyone that there
> is no need for any major changes (ESMTP isn't changing,
> almost all extensions can be done via milters.) All open
> source MTAs basically "simply work", so everyone can choose
> an MTA based on her/his personal preferences.

ESMTP does not change but spam fighting changes requirements for
"bleeding edge" MTA.

>> What's the official status of MeTA1?
> [...]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
NOWPRINT. NOWPRINT. Clemclone, back to the shadows again.
-- The Firesign Theater

Post removed (X-No-Archive: yes)

Post removed (X-No-Archive: yes)

Claus Aßmann wrote:

>> Is Sendmail 8.x going to continue to be developed?

> Yes. However, it should be obvious to everyone that there
> is no need for any major changes (ESMTP isn't changing,
> almost all extensions can be done via milters.)

I don't agree with that. I think there are many useful things that
can still be done with/to Sendmail 8. Here are a few off the top of
my head:

1) Dynamically-loadable extensions. For example, new map types. Having
an official API for writing and loading a shared library would make other
requests (for example, MySQL support) much easier. One could even envision
a dynamically-loaded filtering extension that might be more efficient
than Milter.

2) Code cleanup and removal of obsolete features (how many people still
use UUCP for mail?) Or segregation of obsolete features into
dynamically-loadable modules.

3) APIs for queue manipulation. Right now we have queue groups and
rulesets to choose queue groups, but an API for managing and aging
queues could be pretty useful for very busy sites. Basically, "qtool"
integrated into Sendmail.

> All open source MTAs basically "simply work", so everyone can choose
> an MTA based on her/his personal preferences.

Well, sure, but one of the criteria (and an important one) by which many
judge an open-source project is by the "liveliness" of its
development. By this standard, Qmail is moribund, Sendmail is OK, and
Postfix is pretty good. There are very few widely-used open-source
projects whose developers consider them "finished". About the only
one I can think of is TeX.

>> What's the official status of MeTA1?

> MeTA1 is NOT a Sendmail Consortium project. MeTA1 is under
> development, and the website is updated whenever a new
> version is released.

OK, so has the Sendmail Consortium abandoned the idea of building an
MTA with a completely new architecture? They're going to stick with a
Sendmail-8-like system? (That's OK with me; it'd just be nice to
know!)

Regards,

David.

David F. Skoll wrote:

> I don't agree with that. I think there are many useful things that
> can still be done with/to Sendmail 8. Here are a few off the top of

Sure, but are they worth the effort? If you think they are:
feel free to do it... it's open source after all.

> OK, so has the Sendmail Consortium abandoned the idea of building an
> MTA with a completely new architecture? They're going to stick with a
> Sendmail-8-like system? (That's OK with me; it'd just be nice to
> know!)

Quoting the website:
"The development of sendmail X has been stopped."

In article <Pine.LNX.4.64.0712230959030.28782 [at] ebfjryy.nhfvpf.arg>,
Res <res [at] ausics.net> wrote:

> On Sun, 22 Dec 2007, Claus Assmann wrote:
> > Yes. However, it should be obvious to everyone that there
> > is no need for any major changes (ESMTP isn't changing,
> > almost all extensions can be done via milters.) All open
> > source MTAs basically "simply work", so everyone can choose
> > an MTA based on her/his personal preferences.
>
> Well it would be nice to have native MySQL support, nobody I know
> actually uses ldap so please dont suggest that :)

That says more about you than it does about the world.


> Every person, and I mean every person I know whos left Sendmail to
> postfix says for one of two reasons only these days-
>
> 1/ its ability to natively work with MySQL and virtual domains not
> requiring local user accounts.
> * I agree with this but I still rather use vpopmail with qmail as I
> know it works well.
>
> 2/ its simpler config files
> * I disagree with this, but that might be because I'm a long time
> sendmail user and understand the mc file options, for a newbie it
> could be a daunting task.

The existence of the .mc file is enough to make the case.

The reasons I have seen also include the perception of Postfix's design
being more suited to good security and (more recently) better handling
of very high concurrency through the use of kernel-based event filter
mechanisms like kqueue.

--
Now where did I hide that website...

Claus Aßmann wrote:

[David Skoll wrote some ideas]

> Sure, but are they worth the effort? If you think they are:
> feel free to do it... it's open source after all.

One of the criteria I use to select (or not) open-source projects is
the response "do it yourself... it's open-source after all", which
counts as a strong negative. I don't mean to be ungrateful, but
that's not a helpful response. It's pretty much the response I got
from the GNOME team when I suggested adding the ability for Evolution
to compose e-mails in an external editor.

I've long since given up on all things GNOME because of the GNOME
developers' attitude. The OP made the point that Sendmail seems to be
losing ground. This could be another factor. Sendmail after all
(supposedly) has a commercial enterprise driving its development. If
that's its official response to enhancement suggestions...

Regards,

David.

In comp.mail.sendmail Andrzej Adam Filip <anfi [at] onet.eu>:
> http://www.netbsd.org/docs/guide/en/chap-mail.html
> <quote>
> Note:
> Since NetBSD 4.0, postfix is the default MTA (Mail Transport Agent)
> and sendmail was removed.
> </quote>

Poor choice, if I had to replace sendmail, I'd use exim any day.
For now I am using both sendmail and exim, each were it suits
best.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry [at] urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 456: Noobs anywhere...

David F. Skoll wrote:

> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...

Obviously I don't speak for anyone but myself. If you want
an answer from "a commercial enterprise" you have to ask
them.


Anyway, maybe I should give you some "insider information":
it is obvious that there is very little interest in new
sendmail 8 features that are useful for many people (based
on the mailing list to which I subscribe: postfix, exim,
qmail, ... this applies to other MTAs as well). However,
there is a lot of work going on in other areas, e.g.,
dkim: there are many patches from "users" coming in almost
daily (just look at the release notes and the frequency of
releases). As I wrote before: MTAs are very mature and
basically a "commodity". The interest shifted elsewhere
(filtering, authentication, etc). However, some people
obviously have their own little item(s) which they consider
"important" or at least "interesting", but there are no
overwhelming requests which show me that something needs to
be added.

"Removing UUCP": Why should we do that? What would sendmail
gain? As long as there are people out there who use this it
will stay in. They are in a minority, but at least they
still have an MTA to use.

"Adding support for other maps": someone asks for MySQL and
says "no LDAP", someone else might ask for Postgres or some
other (open source) DB. That's why the "socket" map was
integrated (it was also donated code): it provides a
generic interface. Moreover, if you take a look at map.c
you will find the API for maps documented. That might be a
reason why many implementations for map types were
"donated".

"Queue control": the queue group implementation was a
mistake (just like some other things that happened in
8.12). However, it is "good enough" for most users (it lets
them do almost all of what they want to do).

In article <af799$476e70a9$d1d97a75$11192 [at] PRIMUS.CA>,
"David F. Skoll" <dfs [at] roaringpenguin.com> wrote:

> Claus Aßmann wrote:
>
> [David Skoll wrote some ideas]
>
> > Sure, but are they worth the effort? If you think they are:
> > feel free to do it... it's open source after all.
>
> One of the criteria I use to select (or not) open-source projects is
> the response "do it yourself... it's open-source after all", which
> counts as a strong negative. I don't mean to be ungrateful, but
> that's not a helpful response. It's pretty much the response I got
> from the GNOME team when I suggested adding the ability for Evolution
> to compose e-mails in an external editor.
>
> I've long since given up on all things GNOME because of the GNOME
> developers' attitude. The OP made the point that Sendmail seems to be
> losing ground. This could be another factor. Sendmail after all
> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...

I'm guessing that you've never been a paying customer of Sendmail Inc.
with a need for support, or else you'd likely know the answer to that
'if' pondering.

Their responsiveness was a useful part of a successful pitch I made some
time ago to make a migration from their commercial products to regular
sendmail and a stack of open-source additions.

--
Now where did I hide that website...

Res <res [at] ausics.net> writes:

> On Sat, 22 Dec 2007, Andrzej Adam Filip wrote:
>
>> ESMTP does not change but spam fighting changes requirements for
>> "bleeding edge" MTA.
>
> It does a good job with greet pause, bad helo, require rdns and dns, RBL
> options..
> I dont think there much more it could do,

I can assure you there is a lot more and I dead sure I can not even
imagine big part of it :-)

> ok, it could change 'access.db' to use CIDR's, but I know why it
> doesnt use them and it makes perfect sence and I agree with it.

I do not share your view.

More effective implementation of access lookups is possible based on
btree maps (or future SQL maps) but sendmail.org decided to keep only
solution "fit for all supported database types" (hash,dbm,btree,text).

> It's not really an MTA's job to scan messages for spam and viruses,
> theres already MIMEDefang, MailScanner and a myriad of milters that hook
> spamassassin and virus scanners in to take care of that.

But sendmail can do a lot to help them make the job easier (among many
other things).

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
There are many times when you want it to ignore the rest of the string just
like atof() does. Oddly enough, Perl calls atof(). How convenient. :-)
-- Larry Wall in <1991Jun24.231628.14446 [at] jpl-devvax.jpl.nasa.gov>
## http://groups.google.com/groups?selm=873att5mjv [at] helen.fsf.ho bby-site.com ##

"David F. Skoll" <dfs [at] roaringpenguin.com> writes:

> Claus Aßmann wrote:
>
>>> Is Sendmail 8.x going to continue to be developed?
>
>> Yes. However, it should be obvious to everyone that there
>> is no need for any major changes (ESMTP isn't changing,
>> almost all extensions can be done via milters.)
>
> I don't agree with that. I think there are many useful things that
> can still be done with/to Sendmail 8. Here are a few off the top of
> my head:
>
> 1) Dynamically-loadable extensions. For example, new map types.
> Having an official API for writing and loading a shared library would
> make other requests (for example, MySQL support) much easier.

1) *maps provided by dynamic libraries*
IMHO the best way would be to create *one* new map loading external
a library specified by file path and capable to support many libraries
at once (ala ldap/socket-map to mutiple host:port/sockets).
It would require slight variation of the already provided interface.

Making it work on a selected platform may be easy, porting it to other
platform may be "laborious". Which OS/release do you use? :-)

Allowing sendmail to use libraries provided and maintained by other
project (under possibly different licences) may be helpful.
It may be a great idea for some if we can create template for creating
libraries capable to work with sendmail and exim (and possibly other MTA).

2) *mbdb provided by dynamic libraries*
As above we can use a variation of already defined interface
[ it is an interface "unused" for far ]

3) new interface for "built in" mailers (delivery *without* extra forking)

> One could even envision a dynamically-loaded filtering extension that
> might be more efficient than Milter.

Let's use (or abuse) already existing interfaces first ;-)

> [...]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
If it's working, the diagnostics say it's fine.
If it's not working, the diagnostics say it's fine.
-- A proposed addition to rules for realtime programming
## http://groups.google.com/groups?selm=87hci945ph [at] jason.fsf.ho bby-site.com ##

"David F. Skoll" <dfs [at] roaringpenguin.com> writes:

> Claus Aßmann wrote:
>
> [David Skoll wrote some ideas]
>
>> Sure, but are they worth the effort? If you think they are:
>> feel free to do it... it's open source after all.
>
> One of the criteria I use to select (or not) open-source projects is
> the response "do it yourself... it's open-source after all", which
> counts as a strong negative. I don't mean to be ungrateful, but
> that's not a helpful response.

It is the right answer
*IF* you can contribute without "understanding *full* design"
*IF* they help you a little to make you contribute a lot :-)

> It's pretty much the response I got from the GNOME team when I
> suggested adding the ability for Evolution to compose e-mails in an
> external editor.
>
> I've long since given up on all things GNOME because of the GNOME
> developers' attitude. The OP made the point that Sendmail seems to be
> losing ground. This could be another factor. Sendmail after all
> (supposedly) has a commercial enterprise driving its development. If
> that's its official response to enhancement suggestions...

Sendmail is slowly loosing ground for a long time as it could be
expected based on sendmail history and its previously dominant position.
The problem (as I see it) is that sendmail loses ground without
a proper fight and faster than it should.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Therefore it is necessary to learn how not to be good, and to use
this knowledge and not use it, according to the necessity of the cause.
-- Machiavelli
## http://groups.google.com/groups?selm=8763yp45e5 [at] tana.fsf.hob by-site.com ##

Claus Aßmann
<ca+sendmail(-no-copies-please) [at] mine.informatik.uni-kiel.de> writes:
> [...]
> "Adding support for other maps": someone asks for MySQL and
> says "no LDAP", someone else might ask for Postgres or some
> other (open source) DB. That's why the "socket" map was
> integrated (it was also donated code): it provides a
> generic interface. Moreover, if you take a look at map.c
> you will find the API for maps documented. That might be a
> reason why many implementations for map types were "donated".

What is you opinion about new map capable to use external dynamic
libraries specified by path? [initially for one platform only]

> [...]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Perl programming is an *empirical* science!
-- Larry Wall in <10226 [at] jpl-devvax.JPL.NASA.GOV>
## http://groups.google.com/groups?selm=87y7bl2qpf [at] jean.fsf.hob by-site.com ##

Bill Cole wrote:

[...]

> I'm guessing that you've never been a paying customer of Sendmail Inc.
> with a need for support, or else you'd likely know the answer to that
> 'if' pondering.

No, I've never been a paying customer of Sendmail Inc.

> Their responsiveness was a useful part of a successful pitch I made some
> time ago to make a migration from their commercial products to regular
> sendmail and a stack of open-source additions.

Like Sendmail Inc., we sell commercial software with an open-source
core. However, I listen very carefully to feature requests from
people using the free product, even if they're not paying customers,
for two reasons: (1) their suggestions improve both the free and the
commercial product, and (2) the free product "buys" us incalculable
marketing, so making it as good as possible is in our own interest.

Regards,

David.

Claus Aßmann wrote:

> As I wrote before: MTAs are very mature and
> basically a "commodity". The interest shifted elsewhere
> (filtering, authentication, etc).

Just curious, then: Why are you working on MeTA1? If the existing
free MTAs are good enough and MTAs are commodities, what's the point
of the MeTA1 project?

Regards,

David.

Andrzej Adam Filip wrote:

> What is you opinion about new map capable to use external dynamic
> libraries specified by path? [initially for one platform only]

I'm against specific solutions. It's generic or it's not of
much use. AFAICT there is not good cross-platform support
for doing this (libtool might work, but I heard too many
bad things about it.)

Moreover, it seems loading dynamic libraries is useful for
people who don't have source code, i.e., they can't compile
the code themselves.

David F. Skoll wrote:

> Just curious, then: Why are you working on MeTA1? If the existing
> free MTAs are good enough and MTAs are commodities, what's the point
> of the MeTA1 project?

Because none of the existing MTAs does what I want to do.
Hence I'm working on my own (instead of asking others to
change their MTA or add features that I consider
important). As you certainly have noticed, I appreciate the
input from others, and even if I disagree sometimes, I'm
willing to incorporate their requests, e.g., using
/etc/resolv.conf to find the nameserver addresses, as long
as the basic design (which has been written down in detail)
is not violated.

Once upon a time, Andrzej Adam Filip <anfi [at] onet.eu> said:
>What is you opinion about new map capable to use external dynamic
>libraries specified by path? [initially for one platform only]

How about using an external map server via the socket map type? That
way sendmail doesn't have to be modified for every database type/schema
somebody wants to use.
--
Chris Adams <cmadams [at] hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

On Dec 23, 1:45 pm, Andrzej Adam Filip <a... [at] onet.eu> wrote:
> "David F. Skoll" <d... [at] roaringpenguin.com> writes:
>
> > Claus Aßmann wrote:
>
> > [David Skoll wrote some ideas]
>
> >> Sure, but are they worth the effort? If you think they are:
> >> feel free to do it... it's open source after all.
>
> > One of the criteria I use to select (or not) open-source projects is
> > the response "do it yourself... it's open-source after all", which
> > counts as a strong negative. I don't mean to be ungrateful, but
> > that's not a helpful response.
>
> It is the right answer
> *IF* you can contribute without "understanding *full* design"
> *IF* they help you a little to make you contribute a lot :-)

I did find it possible to learn enough about the specific sections to
write patches.

I did not find any special interest in including any of them.

"Do it yourself" is always true and possible, but people are looking
for the "and I will try to help you" part of the setnence.

jmaimon [at] ttec.com wrote:

> I did find it possible to learn enough about the specific sections to
> write patches.
>
> I did not find any special interest in including any of them.

We sometimes get patches but there doesn't seem to be a
"demand" (by others) for including them. To include a new
feature into sendmail 8 requires at least one of two
things:

a) the maintainer(s) see the value of it;
b) there have been requests from several people to include it.

(there are several other requirements for patches to be
considered of course, e.g., good code quality, doesn't open
security holes, ...)

Currently only the "BadRCPTShutdown" patch seems to fulfill
at least b).

Moreover, if a new feature requires constant maintenance
(because it interfaces with some evolving software), then
it is less likely to be included unless the original author
is willing to maintain the code (e.g., nph map). That's
one way to become a member of the Sendmail Consortium:
provide good code and support...

Anyway, all of this should be well-known (if not from old
postings, then from other open-source projects).

cmadams [at] hiwaay.net (Chris Adams) writes:

> Once upon a time, Andrzej Adam Filip <anfi [at] onet.eu> said:
>>What is you opinion about new map capable to use external dynamic
>>libraries specified by path? [initially for one platform only]
>
> How about using an external map server via the socket map type? That
> way sendmail doesn't have to be modified for every database type/schema
> somebody wants to use.

*Dynamic Libraries as plug-ins*
With a code to load dynamic libraries (implementing specified
interface) as "plug-ins" specified by library name/path there would
be no need to modify sendmail code to support "yet another plug-in"

*Socket map adoption*
"socket map protocol" is not widely supported by "non sendmail" programs.
I am aware only about support socket map support by Cyrus-IMAP.
The support was included even before sendmail move socket map to
official (non FFR) code.
I think socket map protocol misses simple reference implementations
in perl/C/java/python/... under licences typical for the for programs
created in these languages.
[ e.g. its a customary for perl module: "under licence as perl itself"]

*Socket map improvements*
I miss socket map implemented via UDP protocol (connection less
communication). IMHO it would provide much better "decoupling" of MTA
and "map server provider" architectures.
[Pretty good candidate for plug-in (IMHO) :-) ]

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal
----
http://groups.google.com/groups?selm=87fxxsjvo2 [at] roger.fsf.ho bby-site.com

Claus Aßmann
<ca+sendmail(-no-copies-please) [at] mine.informatik.uni-kiel.de> writes:

> Andrzej Adam Filip wrote:
>
>> What is you opinion about new map capable to use external dynamic
>> libraries specified by path? [initially for one platform only]
>
> I'm against specific solutions. It's generic or it's not of
> much use. AFAICT there is not good cross-platform support
> for doing this (libtool might work, but I heard too many
> bad things about it.)

I expected that making it fully portable would be a nightmare :-)
*But* implementing it on a few best suited platforms form set of
platform sendmail is mainly used on should be not too hard
[ if *somebody else* is going to do it ;-) ]

> Moreover, it seems loading dynamic libraries is useful for
> people who don't have source code, i.e., they can't compile
> the code themselves.

From perspective of sendmail source code maintainer it allows to
properly "decouple" maintenance of code.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi [at] priv.onet.pl : anfi [at] xl.wp.pl
Open-Sendmail: http://open-sendmail.sourceforge.net/
Before destruction a man's heart is haughty, but humility goes before honour.
-- Proverbs 18:12
----
http://groups.google.com/groups?selm=878x3kjvcc [at] francis.fsf. hobby-site.com